1.4.4 テストの実装と実行
from 1.4.0 基本的なテストプロセス
テストの実装と実行
テスト設計で行われた大中項目の定義に基づいて、実施手順や確認項目の詳細に変換する
前段階としてテスト実施者のスキルセットを用意する
テストウェアを記述する粒度に影響する
ユーザー指向のテストだと開発視点が邪魔になることもある
テスト実施者の適性を見る必要がありそう
テストの実装と実行のアクティビティ
テストケースを決定し、実装し、優先順位をつける
テスト設計仕様を元にテストケースを作成する
ドキュメントとしてはテストケースとテスト手順書は別（IEEE829的に）
当初のテスト計画、テスト設計で決めた優先順位が変わることもある
テスト条件をまたがってテストスイートをまとめることも多い
テストの準備や後片付けなどの手間によっては順番を変えたほうが効率良いことも
テスト手順を開発し、優先順位をつけ、テストデータを作成する。場合によってはテストハーネスを準備し、テストの自動実行スクリプトを書く
テストハーネス = テストツールに組み込まれたライブラリ（xUnit, Seleniumなどのことを指している？）
基本手順作成、データ作成、ハーネス準備は平行だか、ハーネスの仕様が固まらないと始まらないことも
効率よくテストを実行するため、テスト手順をベースにテストスイートを作る
実施効率を考えた上でテストケースを組み合わせてまとめていく
フォールト指向でいくなら、異常パターンをまとめたテストスイートにするなど
テスト実施効率に直接影響するので、テスト実施者が作成していく
テスト環境が正しくセットアップしたことを確認する
テスト実施環境の整備
テスト対象のセットアップ
テストツール、テストハーネス、計測機器などの設備の準備
外部システム、外部機器の準備
テストベースとテストケースの間で双方向のトレーサビリティを確認し更新する
トレーサビリティマトリクスの作成で確保する
テストベースの変更があった時点で関連するテストケースも変更する
仕様変更、インシデント対応による機能追加など
計画した順番に従い、テスト手順を人力、もしくはテストツールで実行する
計画に従って実行するタスク
テスト実行結果の記録を取り、テスト対象のソフトウェア、テストツール、テストウェアのIDとバージョンを記載する
テスト結果を定めた方法によって記録していく
テストを実施した環境（OS、システム構成、ハードウェアなど）、ツールの構成やバージョンもエビデンスとして残す
テスト実行結果と期待する結果を比較する
両者が一致しない場合、インシデントとして報告し、原因（コード、テストデータやテストドキュメントの欠陥、テスト実行手法の誤りなど）を解明するためにインシデントを分析する
期待結果と実行結果があってれば問題なし
あってない場合はインシデント報告
他の要因で同一事象が起こるか
他の機能に影響が出ていないか
記録したものの呼ばれ方 = インシデントログ、インシデントレポート、不具合報告書、バグレポート、問題点処理表、バグチケットなどなど
実行結果と期待する結果が一致しないケースごとに、テスト活動を繰り返す。
題目が長いので以下にまとめます。
確認テスト
修正が正しいことを確認するため、前回不一致となったテストケースを再実行する
改訂版のテストケースや元のテストケースを実行
回帰テスト
変更していないプログラム部分に新たな欠陥が入り込んでいないことや。欠陥の修正により影に隠れていた欠陥が現れないことを確認する
全てが終わった後に主要なテストケースを再度実施する
次の開発プロセスやテストレベルに移行できるかの判断材料にも使える